Applying GitOps Principles Using Argo CD

Introduction#

Argo CD describes itself as “a declarative, GitOps continuous delivery tool for Kubernetes.” That could be considered misleading. Argo CD is not a “continuous delivery tool.” It needs more to be able to claim that.

Continuous delivery (CD) is the ability to deploy changes to production as quickly as possible, without sacrificing quality and security. On the surface, it might sound like a tool that can deploy changes to production as a CD tool, but that's not the case. Continuous delivery is about automating all the steps from a push to a code repository all the way until a release is deployed to production. As such, Argo CD doesn't fit that description. Here's what we want to achieve from any CI/CD tool.

We wanted to get all this out of the way right away so there are no false expectations.

So, let's change the official description of Argo CD to a “declarative GitOps deployment tool for Kubernetes.”

Our initial negativity shouldn't diminish the value of Argo CD. It's one of the best, if not the best tool we have today to deploy applications inside Kubernetes clusters. It's based on GitOps principles, and it's a perfect fit to be a part of continuous delivery pipelines. It provides all the building blocks we might need if we would like to adopt GitOps principles for deployments and inject them inside the process of application lifecycle management.

Now, let's give a different explanation of what Argo CD is.

Argo CD is a tool that helps us forget the existence of kubectl apply, helm install, and similar commands. It's a mechanism that allows us to focus on defining the desired state of our environments and pushing definitions to Git. It's up to Argo CD to figure out how to converge our desires into reality.

Now let's jump straight into examples, and, through them, we’ll discuss the process, the patterns, and the architecture.

Let’s go!

Installing And Configuring Argo CD#

We’ll run Argo CD inside a Kubernetes cluster. That's our first requirement.

We’ll need a Kubernetes cluster with the NGINX Ingress controller. The address through which we can access Ingress should be stored in the environment variable INGRESS_HOST. There are a few other things we’ll need. We’ll get to them soon. For now, let’s focus on a cluster.

Note: All the commands from this section are available in the lesson. Feel free to use it for copying and pasting.

As always, we've prepared Gists for creating clusters based on Docker Desktop, Minikube, Google Kubernetes Engine (GKE), AWS Elastic Kubernetes Service (EKS), and Azure Kubernetes Service (AKS). Use them, or roll out your own cluster. Just remember that if you make your own, you might need to change a command or two for the following examples:

• Docker Desktop

• Minikube

• GKE

• EKS

• AKS

Note: All the commands for the setups mentioned in the the list above are given in the lesson. Feel free to use them.

Now that we have a cluster with Ingress and the address stored in the environment variable INGRESS_HOST, we’ll need to ensure that we have the helm CLI. We’ll use it to deploy all the tools we’ll need as well as a demo app. If you don’t have it, please visit the Installing Helm page for the information. For experimenting with commands on our platform, we've already installed Helm for you.

Now we're ready to install Argo CD. We could install it with kubectl or Kustomize, but given that we already have helm, and that the demo applications we’ll use are based on Helm charts, it's probably the best choice, at least within the context of our exercises.

As you'll see later, this might be the last application you’ll ever install by executing ad hoc commands from a terminal. Once we’re finished exploring Argo CD, you might decide to remove helm from your laptop.

The first step is to create a namespace where Argo CD will reside.

Next, we need to add the repo with Argo charts to the local Helm repository.

We won't be able to install the chart as is. We’ll need to make a few tweaks so that it works in our cluster. We’ll do that by providing helm with a few additional values. So, let’s take a quick look at what we have.

The output is as follows.

We're enabling ingress so we can access Argo CD UI from a browser. Since we don't have SSL certificates, we'll let it know that it's okay to be insecure.

Note: If you choose to use Argo CD “for real,” you shouldn't do that. You should use certificates for all public-facing applications and mutual TLS for internal traffic.

Later on, we set installCRDs to false. Helm 3 removed the install-crds hook, so CRDs need to be installed as if they are “normal” Kubernetes resources. Think of it as a workaround.

There’s one thing that's missing from that YAML. It doesn't contain the server.ingress.hosts value. We don't know the address through which your cluster is accessible, so we’ll set that one through the --set argument.

Note: We’ll use nip.io since we can't assume that you have a “real” domain that you can use for the exercises or, if you do, that you've configured its DNS to point to the cluster.

That’s it. Now we’re ready to install Argo CD.

Let’s take a look at the password itself.

The output, in our case, is as follows.

That will be a difficult password to remember, so let’s change the password to something else.

You'll be asked to provide the existing password. Copy and paste the output of echo $PASS. Later on, you'll be asked to enter a new password twice.

We're finally ready to open Argo CD UI.

Please type "admin" as the username and whatever you chose for the password.

Click the "SIGN IN" button.

After signing in, you'll be presented with the Argo CD home screen that lists all the applications. We don't have any, so there's not much to look at. We’ll change that soon.

Let’s take a look at the Pods that constitute Argo CD.

The output is as follows.

We got a few distinct components. We won't go into details about what they are and what they’re used for. That’s reserved for a different occasion. For now, the important thing to note is that they're all Running, so we can assume that Argo CD was installed correctly.

For now, we have a Kubernetes cluster with Argo CD running inside. It can be accessed through the UI or through Kube API.

With Argo CD up and running, we can move to the more exciting part of the exercises.

Note: We'll get hands-on experience with the concepts and commands that are discussed in this lesson in the project "Hands-on: Deploying Applications Using GitOps Principles" right after this chapter.